uno: zeroize per-IO DMA buffers on teardown using the GDMA engine - #632

Internal provisioning (partition identity, enable-time keygen, boot-key
masking, vault teardown) runs on the reserved admin IO slot rather than a
host IO, so it never reaches drop_io. Its scratch was only watermark-
rewound, never wiped, leaving raw private-key material (e.g. the P-384
identity scalar) resident in the slot indefinitely.

Add UnoHsmPal::with_admin_io, the admin-side counterpart of drop_io: it
opens an admin IO plus a rewound scoped allocator, runs the caller's async
closure, then scrubs the slot. Binding the scrub to the session rather than
to each caller means no admin path can forget it, and the higher-ranked
bound stops any scratch from escaping past the scrub.

ensure_unwrapping_key_imported is left as-is: it is a synchronous fn whose
atomicity against the cooperative scheduler is load-bearing, and it feeds
the &'static GSRAM blob straight into the vault with no DMA-scratch copy.

Also fix a clippy manual_is_multiple_of warning in cpu_zeroize.

`with_admin_io`'s higher-ranked bound stops the closure returning anything
borrowed from the session's scoped allocator, and the doc claimed that meant
no scratch could outlive the scrub. That was not quite true: the closure
captures the PAL, and the PAL-level `dma_alloc` hands back a buffer whose
lifetime is tied to the PAL, not to the session. A closure could return one
and the caller would silently receive memory the scrub had just zeroed.

Add `R: 'static`. Every caller already returns an owned value, so this costs
nothing, and it turns the doc claim into something the compiler checks: an
attempt to return a PAL-level buffer out of the session now fails to compile
with "returning this value requires that `'1` must outlive `'static`".

Also record why `ensure_unwrapping_key_imported` still takes a raw admin IO
instead of a session: it is synchronous, so it cannot await a scrub, and it
allocates no scratch — `create_sync` copies from the `&'static` GSRAM slot
straight into vault storage — so there is nothing to wipe. Without the note
it reads like an omission.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 2444329e-909e-4ced-b5df-5a40fb65bb6c

The teardown scrub wiped each slot's full capacity — 18 KiB of SRAM and
1.5 KiB of DTCM — however little the command touched. The live bump
watermark cannot bound that, because it rewinds on every scope exit, so
track a per-(slot, heap) peak that only grows and wipe to that instead.

The peak is cleared by the scrub rather than by the allocator reset, so it
always means "bytes written since the last scrub". Everything past it is
already zero from that scrub, and an IO that ends without one keeps its
peak, so the next scrub still covers it.

`dma_alloc_var*` need care: they reserve the whole remaining heap so the
callback need not know its encoded length up front, which would pin the
peak at capacity on every IO. They now snapshot the peak before the
reservation and restore it to the trimmed length, and document the contract
this rests on — the callback must not write past the length it returns. On
the error path the peak is left at the full reservation, since a partial
write before the failure is unbounded.

Measured on hardware over ~1.7k IOs: the DMA peak averages ~933 B of the
18 KiB slot with a maximum of ~3.3 KiB, so the wipe now fits in a single
DUMMY_MEM-sized GDMA transfer instead of two. Instrumenting the scrub to
scan each slot's whole capacity afterwards found no non-zero byte past the
recorded peak, on any slot, in any run.

Also in this change:

- `zeroize_mem` wipes through the GDMA engine rather than the CPU, falling
  back to a volatile CPU wipe if the engine has no free tag. Every `DmaBuf`
  is GSRAM-backed by construction — the DTCM heap hands out plain
  `&mut [u8]` — so the destination is always GDMA-reachable.

- `UnoHsmIo::admin` becomes `admin_no_scrub`, so a path that opts out of the
  scrubbed session has to say so. Its one caller is the synchronous
  unwrapping-key import, which cannot await a scrub and writes nothing to
  either bump heap.

- `delete_key` takes the caller's admin IO instead of opening a session per
  key. `KeyVault::delete` takes no allocator, so it cannot dirty the heaps,
  and `clear_enabled_state` deletes one key per provisioning slot and per
  live session — a session each would have scrubbed the slot every time for
  no benefit.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 2444329e-909e-4ced-b5df-5a40fb65bb6c